Sympa la fonction dans les commentaires, mais pour un gros historique, penser à rajouter un "-l 3" au svn log pour avoir seulement l'historique des 3 derniers changements.
La version modifée avec le "-l 3" :
#
function history_of_file() {
url=$1 # current url of file
svn log -l 3 -q $url | grep -E -e "^r[[:digit:]]+" -o | cut -c2- | sort -n | {
echo
read r
svn log -r$r $url@HEAD
svn cat -r$r $url@HEAD
echo
while read r
do
echo
svn log -r$r $url@HEAD
svn diff -c$r $url@HEAD
echo
done
}
}
history_of_file $1
-
http://stackoverflow.com/questions/282802/how-can-i-view-all-historical-changes-to-a-file-in-svnDans la vue Discover de Kibana4, si vous ne voyez pas tous les champs d'une entrée....
Tentez cette manip' : Settings > Indices > Select your indice (logstash-*) > then refresh..
Cette liste a parfois du mal à se rafraichir si il y a trop de documents/de champs (PS : plusieurs heureuse de debug sans résultat, la solution m'a été donnée sur irc : freenode#kibana) thx rashidkpc
-
https://links.infomee.fr/?ANfw7ALe système de plugin d'elasticsearch est vraiment bien foutu.
Quelques plugins sympa pour avoir un aperçu de la santé de son cluster :
https://github.com/karmi/elasticsearch-paramedic
https://github.com/mobz/elasticsearch-head
https://github.com/lukas-vlcek/bigdesk
Pour les installer, c'est à chaque fois pareil, en une ligne :
/usr/share/elasticsearch/bin/plugin -install lukas-vlcek/bigdesk
/usr/share/elasticsearch/bin/plugin -install karmi/elasticsearch-paramedic
/usr/share/elasticsearch/bin/plugin -install mobz/elasticsearch-head
Pour savoir quels plugins sont installés et par quelle urls y accéder :
curl -s -XGET 'http://localhost:9200/_nodes?pretty' | grep plugin
-
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-plugins.htmlrsyslog intègre une limitation soft pour ne pas pourrir les IO en cas de mass logs non voulus
Dans certains cas les valeurs par défaut sont un peu faible, suffit de les up un peu en surveillant les io disk ;)
-
http://www.rsyslog.com/tag/rate-limiting/| awk '{total = total + $1}END{print total}'
find . ! -newer /tmp/file2015 -exec ls -l --block-size=M {} \; |cut -d' ' -f5|sed 's/M//'| awk '{total = total + $1}END{print total}'
-
http://stackoverflow.com/questions/926069/add-up-a-column-of-numbers-at-the-unix-shellJe me demandais pourquoi le status de mes index étaient à yellow, en fait c'est tout à fait normal dans un cluster mono node :-)
-
http://chrissimpson.co.uk/elasticsearch-yellow-cluster-status-explained.htmlDécouverte sympa, même si je reste fan de rsnapshot et de ses hardlink
-
https://attic-backup.org/Si vous utilisez le fileserver de puppet et que vous gérez beaucoup de petits fichiers avec, il y a surement des optimisations à faire !
En effet pour chaque fichier, le client va demander un hash au serveur et en établissant à chaque fois une nouvelle connexion tcp... le temps perdu 2,5 secondes pour 10 fichiers..
Pour voir tout ça, rdv dans les logs du puppet master et regarder les lignes : GET /production/file_metadata pour vous donner une idée
La solution est de se passer du fileserver pour ces petits fichiers et de les inclure directement dans le catalogue, en utilisant :
content => file(path)
au lieu de source => puppet:///
Ici on est passé de 14seconde à 5,5seconde
-
https://docs.puppetlabs.com/guides/file_serving.htmlVoxygen, éditeur de la synthèse vocale de dernière génération, expert en voix expressives, vous accompagne dans la définition de votre stratégie vocale.
-
http://www.voxygen.fr/frIl existe plusieurs alternatives à carbon, la plus connu étant surement influxdb. Celle ci est basée sur cassandra!
+https://github.com/kairosdb/kairos-carbon
via arnaudb
-
https://github.com/kairosdb/kairosdbLe principe des table de hash distribuées
-
http://www.freedomlayer.org/articles/dht_intro.html